The model-view-controller (MVC) design pattern assigns objects in an application one of three roles: (i) model, (ii) view, or (iii) controller. The design pattern defines the roles objects play in the application and the way objects communicate with each other. Each of the three types of objects is separated from the others by abstract boundaries. One way to easily envision MVC is as follows: (i) the model object is the data; (ii) the view object is the window on the screen; and (iii) the controller object is the glue between the two. Several enterprise web applications running on multi-tier level architectures implement the MVC design pattern where the view layer is usually placed on the server-side. Such an implementation was preferred in the past because the processors lacked power to host view logic. Over the years, the vast improvements in processor performance have opened opportunities to split the implementation between client and servers. Such opportunities for new solutions increase both usability and performance.
Model objects, in a MVC architecture, encapsulate data specific to an application. Model objects encapsulate the logic to manipulate and process data. Model objects usually represent concrete items, such as a contact in a phone's address book.
A view object, or known simply as a view, is an object in an application that users can observe. Two major purposes of view objects are to display data from the application's model objects and to enable the editing of that data. A view object knows how to draw itself. A view object can respond to user actions. A view for a contact in a phone's address book would know how to display the contact and allow editing of it.
A controller object acts as an in-between from one or more of an application's view objects to one or more of its model objects; they are conduits. A controller object interprets user's actions made within view objects and communicates new or updated data to the model layer.